1. Field of the Invention
The present invention relates to computer program code and a method for communicating with a process running on a virtual machine. By way of illustrative example of a preferred embodiment of the present invention reference will be made to a single sign-on application that passes user credentials to a Java applet running on a Java Virtual Machine. It is to be understood however that the present invention is applicable for communicating with a process running on a virtual machine in contexts other than single sign on applications.
It is also to be understood that the term “process” it to be understood as having a broad meaning encompassing any executable computer code or data, whether compiled or interpreted, including but not limited to threads, procedures, scripts and programs.
2. Discussion of the Related Art
When computers were first deployed, such as in a work environment, there was generally a single computer, (such as mainframe or minicomputer) shared by a number of users, who accessed the computer via “dumb” terminals. A user would authenticate their identity when logging in by entering a user name and password into their terminal and thereby gaining access to the resources (i.e. programs and data) of the computer. Since there was only a single computer, the authentication process only had to be performed once per user session.
With the establishment of local area networks linking PCs and/or workstations, minicomputers and mainframes, users often had to authenticate themselves to their own workstation to gain initial access to the network, and then separately to each network node on which a required resource resided. However, the maximum number of nodes on local area networks was fairly constrained, meaning that the number of different log-in names and passwords that a user needed to know was manageable.
Most local area networks are now connected to wide area networks and principally the Internet. With Internet connectivity users have access to effectively limitless resources residing on globally dispersed network nodes. For example, as illustrated in FIG. 1, a user workstation 100, such as a PC, is connected to a network 102. Typically the workstation 100 is connected to a local area network (LAN). In turn, the LAN is connected via an Internet Service Provider (ISP) (not shown) to a router (not shown) that provides access to the Internet. The LAN may also be connected via the telephone system to other LANs to form extranets. The network 102 illustrated in FIG. 1, refers to LANs (including extranets), wide area networks and the Internet.
Network connectivity allows user access to resources residing on an Application Server 104 that runs applications for the user and delivers output to the user workstation 100. Applications may also run directly on the user workstation and have access to file servers 106, print servers 108 and email servers 110 residing on the LAN or on other networks including the Internet.
The user workstation 100 also has access to resources on a mainframe/Unix Host 112 that are accessed via terminal emulator software, using a protocol such as TN 3270, running on the user workstation. Network connectivity also allows access to any number of services 114 available on the World Wide Web, such as internet banking, online auctions, online retailers, commercial databases (such as Lexis or Dialog) and web mail
Potentially, a user may have to authenticate themselves each time they wish to access a particular resource, meaning that a large volume of authentication credentials (such as user names, and passwords) needs to be remembered. Additionally, for security purposes, many services require that a password be changed on a regular basis, thus adding to the confusion and difficulty in managing authentication credentials.
In an attempt to better manage authentication of user credentials Single Sign On (SSO) systems have been developed. SSO allows automation of the authentication process, whereby users authenticate themselves once, with the SSO system then managing subsequent authentications if and when required. In some cases, SSO is provided by an authentication server 116, accessible to the user work station 100 over the network 102. Alternatively, the SSO system can run directly on the user workstation 100 or on both the workstation 100 and server 116. A database (such as an X.500 based Directory) of authentication credentials 118 is accessible to the SSO system. For security purposes the authentication credentials are stored in encrypted form.
An overview of an SSO system is given by reference to FIG. 2. Generally, the SSO system runs as a background process on the user workstation 100 in step 202. At step 204, data that is indicative of the state of a user interface (hereinafter referred to as “user interface state data”) presented on the user workstation is examined to detect whether there is a log-in opportunity. This step is typically implemented via services provided by the operating system as understood by those skilled in the art. For example the Windows operating system provides application programming interfaces (API's) that allow an application to be notified of various user interface events. This mechanism, known as “Windows hooking”, allows the application to determine when a window is created, what the window contains and properties of the window such as its title, position and others. After detecting a log-in opportunity at step 206, the SSO system determines the particular resource related to the log-in opportunity (such as application, mainframe, web service etc) and retrieves the relevant authentication credentials from the database 118. These credentials are then applied at step 210 to the user interface object, such as by entering the user name and password to thereby complete the authentication process. The user is thus relieved from having to remember and enter the correct user name and password to access a particular resource.
The resources accessed by the SSO system may exist on the user workstation 100 as an application program, as is illustrated in FIG. 3. In this case, an application program 300 (for example a terminal emulator or email client) uses operating system 302 services such as a user interface 304 to perform its tasks. The SSO system 200 is also an application program that, as noted above, uses operating system services to authenticate the user to particular resources.
However, some resources do not exist as an application program running directly on the operating system 302, but rather as a process running on a virtual machine 304. A virtual machine can be described as a software simulated machine providing the operational equivalent of a real machine that does not exist as a physical entity per se. A virtual machine 304 takes instructions from a process 306 and converts them to instructions that are recognisable by the operating system 302 and hardware 308 on which the virtual machine 304 runs.
For example, as illustrated in FIG. 4 a web browser 310 such as Microsoft Internet Explorer exists as an application program running on an operating system 302 (such as Microsoft Windows), which in turn is running on particular hardware 308 (such as an Intel processor with memory and peripherals). The web browser 310 implements a virtual machine 304 on which processes may be run. In particular, a Java applet 306 delivered as part of a web page to the web browser 310 over the internet 102, exists as a process that runs on the virtual machine 304 (for example the JVM developed by Sun Microsystems).
The Java applet uses services provided by the virtual machine, to instructions recognisable by the operating system 302 and hardware 308 implementing the virtual machine 304. The Java programming language was developed by Sun Microsystems and has been successful due to its cross platform portability, in that a single Java program may be written for any platform that implements the JVM. Thus, the same applet may be written for and run on a platform employing, for example, the Microsoft, Unix, Linux or Macintosh operating system or indeed any platform that implements a JVM.
Numerous web based services provide authentication prompts, such as requests for user names and passwords via a Java applet that is downloaded to the user's browser and runs on a virtual machine. An effective SSO system would allow authentication to any resource, irrespective of how the resource exists on a user workstation 100. Whilst current SSO systems allow accurate authentication to a resource existing as an application program, they are less successful where the resource exists as a process running on a virtual machine. Thus SSO systems could be improved to allow authentication into a virtual machine. Also, it would be advantageous to communicate with processes running on virtual machines for other purposes.